<?php
/**
 * <https://y.st./>
 * Copyright © 2018 Alex Yst <mailto:copyright@y.st>
 * 
 * This program is free software: you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation, either version 3 of the License, or
 * (at your option) any later version.
 * 
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
 * GNU General Public License for more details.
 * 
 * You should have received a copy of the GNU General Public License
 * along with this program. If not, see <https://www.gnu.org./licenses/>.
**/

$xhtml = array(
	'<{title}>' => 'Autoloading in Hack',
	'takedown' => '2017-11-01',
	'<{body}>' => <<<END
<section id="dreams">
	<h2>Dream journal</h2>
	<p>
		I dreamed I was a small child keeping a daily, online journal.
		My only (in the dream) sibling, with whom I was very close, kept daily pages in the same journal.
		I was horrified to learn that a serial killer was on the loose, and that they were using elements from our journal in their crimes.
	</p>
</section>
<section id="university">
	<h2>University drudgery</h2>
	<p>
		My discussion post for the day was as follows:
	</p>
	<blockquote>
		<p>
			You make a couple of interesting points about two-pass assemblers.
			Most importantly, you say they&apos;re easier to maintain than one-pass assemblers.
			I haven&apos;t been able to get the TECS software suite running, we&apos;ve been given zero instruction on how to do so, and the TECS software suite manual is hosted only on a website that blocks my $a[IP] address.
			As a result, I haven&apos;t been able to use the regular assembler, and I had to build my own assembler this week.
			While both assembly methods were easy to understand at a high level, the two-pass method was much easier to understand at a low level, making it easier to build.
			I imagine the simplicity of the logic will make it easy to maintain as well, while a one-pass assembler would be harder to understand, and therefore harder to maintain.
			I hadn&apos;t considered that.
			You also mention that the first pass involves recording the addresses in which instructions will be loaded.
			My first pass eliminates comments and empty lines as it records the labels, leaving behind only the instruction lines.
			Basically, that records via the array structure what address each command will reside in, but I hadn&apos;t thought of it that way.
		</p>
	</blockquote>
</section>
<section id="PHP">
	<h2>$a[PHP] and Hack</h2>
	<p>
		On a whim, I decided to do a Web search to see if Hack includes autoloading.
		Of course Hack would include this $a[PHP] feature, why on earth would Facebook remove it?
		What I found shocked me though: Hack allows, in addition to class autoloading, function and constant autoloading!
		This lack of autoloading functions and constants is one of my primary complaints in $a[PHP].
		Alright, I&apos;ve seen enough.
		I want Hack to be the future of include.d.
		I might try out Hack ahead of schedule, if time allows.
		That said ... I demand that include.d run on Debian Stable with no outside software.
		I can install outside software on my own machine, but I have no interest in requiring others do the same to use my library.
		That means that while I can experiment and I can convert my site-building code, I can&apos;t actually convert include.d itself until $a[HHVM] reaches Debian Stable.
		If it even does.
		It&apos;s not in Debian Testing, and not everything in Debian Unstable even makes it to Debian Testing.
		Debian 8 didn&apos;t even include Midori, even though Debian 7 did and Debian 9 does.
		If $a[HHVM] drops out of Debian Stable after arriving like Midori did, even temporarily, it&apos;s going to be a major pain in the neck, as I&apos;ll have to translate back to $a[PHP] and drop the new features I&apos;ve used.
	</p>
	<p>
		The autoload functionality makes no sense to me; it appears to require the name of all potentially-autoloaded constructs to be manually specified by name and file name.
		That makes ... no sense.
		In what way is that autoloading?
		The whole point of autoloading is that you don&apos;t have to keep such a list, which would otherwise need to be maintained in the form of a block of <code>require</code> statements.
		A list is a list though; no matter what form you keep it in, the maintenance is too much trouble.
		That said, there&apos;s a &quot;failure&quot; callback that can be called when autoload fails, and that callback can be used to autoload everything in a way that&apos;s actually sane.
		The important thing here is that this allows us to hook into the event of constants and functions being used when not yet defined, gives our callback the information needed to know what component is needed, and lets us redefine the event as a success and not a failure.
		$a[PHP] proper doesn&apos;t have that option, and there&apos;s no way to hook into that sort of thing except in the case of classes.
	</p>
	<p>
		There&apos;s another feature form $a[PHP] that I was going to make sure was preserved, but after the autoloading shock, I&apos;ve totally forgotten what it was.
	</p>
</section>
END
);
